home *** CD-ROM | disk | FTP | other *** search
/ AmigActive 2 / AACD 2.iso / AACD / Programming / perlman / man / perlsec.txt < prev    next >
Encoding:
Text File  |  1999-09-09  |  7.7 KB  |  165 lines
  1. NAME
  2.        perlsec - Perl security
  3.  
  4. DESCRIPTION
  5.        Perl is designed to make it easy to write secure setuid
  6.        and setgid scripts.  Unlike shells, which are based on
  7.        multiple substitution passes on each line of the script,
  8.        Perl uses a more conventional evaluation scheme with fewer
  9.        hidden "gotchas".  Additionally, since the language has
  10.        more built-in functionality, it has to rely less upon
  11.        external (and possibly untrustworthy) programs to
  12.        accomplish its purposes.
  13.  
  14.        Beyond the obvious problems that stem from giving special
  15.        privileges to such flexible systems as scripts, on many
  16.        operating systems, setuid scripts are inherently insecure
  17.        right from the start.  This is because that between the
  18.        time that the kernel opens up the file to see what to run,
  19.        and when the now setuid interpreter it ran turns around
  20.        and reopens the file so it can interpret it, things may
  21.        have changed, especially if you have symbolic links on
  22.        your system.
  23.  
  24.        Fortunately, sometimes this kernel "feature" can be
  25.        disabled.  Unfortunately, there are two ways to disable
  26.        it.  The system can simply outlaw scripts with the setuid
  27.        bit set, which doesn't help much.  Alternately, it can
  28.        simply ignore the setuid bit on scripts.  If the latter is
  29.        true, Perl can emulate the setuid and setgid mechanism
  30.        when it notices the otherwise useless setuid/gid bits on
  31.        Perl scripts.  It does this via a special executable
  32.        called suidperl that is automatically invoked for you if
  33.        it's needed.
  34.  
  35.        If, however, the kernel setuid script feature isn't
  36.        disabled, Perl will complain loudly that your setuid
  37.        script is insecure.  You'll need to either disable the
  38.        kernel setuid script feature, or put a C wrapper around
  39.        the script.  See the program wrapsuid in the eg directory
  40.        of your Perl distribution for how to go about doing this.
  41.  
  42.        There are some systems on which setuid scripts are free of
  43.        this inherent security bug.  For example, recent releases
  44.        of Solaris are like this.  On such systems, when the
  45.        kernel passes the name of the setuid script to open to the
  46.        interpreter, rather than using a pathname subject to
  47.        mettling, it instead passes /dev/fd/3.  This is a special
  48.        file already opened on the script, so that there can be no
  49.        race condition for evil scripts to exploit.  On these
  50.        systems, Perl should be compiled with
  51.        -DSETUID_SCRIPTS_ARE_SECURE_NOW.  The Configure program
  52.        that builds Perl tries to figure this out for itself.
  53.  
  54.        When executing a setuid script, or when you have turned on
  55.        taint checking explicitly using the -T flag, Perl takes
  56.        special precautions to prevent you from falling into any
  57.        obvious traps.  (In some ways, a Perl script is more
  58.        secure than the corresponding C program.)  Any command
  59.        line argument, environment variable, or input is marked as
  60.        "tainted", and may not be used, directly or indirectly, in
  61.        any command that invokes a subshell, or in any command
  62.        that modifies files, directories, or processes.  Any
  63.        variable that is set within an expression that has
  64.        previously referenced a tainted value also becomes tainted
  65.        (even if it is logically impossible for the tainted value
  66.        to influence the variable).  For example:
  67.  
  68.            $foo = shift;               # $foo is tainted
  69.            $bar = $foo,'bar';          # $bar is also tainted
  70.            $xxx = <>;                  # Tainted
  71.            $path = $ENV{'PATH'};       # Tainted, but see below
  72.            $abc = 'abc';               # Not tainted
  73.  
  74.            system "echo $foo";         # Insecure
  75.            system "/bin/echo", $foo;   # Secure (doesn't use sh)
  76.            system "echo $bar";         # Insecure
  77.            system "echo $abc";         # Insecure until PATH set
  78.  
  79.            $ENV{'PATH'} = '/bin:/usr/bin';
  80.            $ENV{'IFS'} = '' if $ENV{'IFS'} ne '';
  81.  
  82.            $path = $ENV{'PATH'};       # Not tainted
  83.            system "echo $abc";         # Is secure now!
  84.  
  85.            open(FOO,"$foo");           # OK
  86.            open(FOO,">$foo");          # Not OK
  87.  
  88.            open(FOO,"echo $foo|");     # Not OK, but...
  89.            open(FOO,"-|") || exec 'echo', $foo;        # OK
  90.  
  91.            $zzz = `echo $foo`;         # Insecure, zzz tainted
  92.  
  93.            unlink $abc,$foo;           # Insecure
  94.            umask $foo;                 # Insecure
  95.  
  96.            exec "echo $foo";           # Insecure
  97.            exec "echo", $foo;          # Secure (doesn't use sh)
  98.            exec "sh", '-c', $foo;      # Considered secure, alas
  99.  
  100.        The taintedness is associated with each scalar value, so
  101.        some elements of an array can be tainted, and others not.
  102.  
  103.        If you try to do something insecure, you will get a fatal
  104.        error saying something like "Insecure dependency" or
  105.        "Insecure PATH".  Note that you can still write an
  106.        insecure system call or exec, but only by explicitly doing
  107.        something like the last example above.  You can also
  108.        bypass the tainting mechanism by referencing
  109.        subpatterns--Perl presumes that if you reference a
  110.        substring using $1, $2, etc, you knew what you were doing
  111.        when you wrote the pattern:
  112.  
  113.            $ARGV[0] =~ /^-P(\w+)$/;
  114.            $printer = $1;              # Not tainted
  115.  
  116.        This is fairly secure since \w+ doesn't match shell
  117.        metacharacters.  Use of /.+/ would have been insecure, but
  118.        Perl doesn't check for that, so you must be careful with
  119.        your patterns.  This is the ONLY mechanism for untainting
  120.        user supplied filenames if you want to do file operations
  121.        on them (unless you make $> equal to $< ).
  122.  
  123.        For "Insecure $ENV{PATH}" messages, you need to set
  124.        $ENV{'PATH'} to a known value, and each directory in the
  125.        path must be non-writable by the world.  A frequently
  126.        voiced gripe is that you can get this message even if the
  127.        pathname to an executable is fully qualified.  But Perl
  128.        can't know that the executable in question isn't going to
  129.        execute some other program depending on the PATH.
  130.  
  131.        It's also possible to get into trouble with other
  132.        operations that don't care whether they use tainted
  133.        values.  Make judicious use of the file tests in dealing
  134.        with any user-supplied filenames.  When possible, do opens
  135.        and such after setting $> = $<.  (Remember group IDs,
  136.        too!) Perl doesn't prevent you from opening tainted
  137.        filenames for reading, so be careful what you print out.
  138.        The tainting mechanism is intended to prevent stupid
  139.        mistakes, not to remove the need for thought.
  140.  
  141.        This gives us a reasonably safe way to open a file or
  142.        pipe: just reset the id set to the original IDs.  Here's a
  143.        way to do backticks reasonably safely.  Notice how the
  144.        exec() is not called with a string that the shell could
  145.        expand.  By the time we get to the exec(), tainting is
  146.        turned off, however, so be careful what you call and what
  147.        you pass it.
  148.  
  149.            die unless defined $pid = open(KID, "-|");
  150.            if ($pid) {           # parent
  151.                while (<KID>) {
  152.                    # do something
  153.                }
  154.                close KID;
  155.            } else {
  156.                $> = $<;
  157.                $) = $(;  # BUG: initgroups() not called
  158.                exec 'program', 'arg1', 'arg2';
  159.                die "can't exec program: $!";
  160.            }
  161.  
  162.        For those even more concerned about safety, see the Safe
  163.        and Safe CGI modules at a CPAN site near you.  See the
  164.        perlmod manpage for a list of CPAN sites.
  165.